[小ネタ]Amazon EMRクラスターで使用するAmazon EC2インスタンスのスペックをケチると、クラスターが動かないことがある

Amazon EC2インスタンスタイプのメモリが小さすぎると、Amazon EMRクラスターのステータスが「実行中」のまま動かなくなることがあります。他の設定が原因であることもあるので、正確にログを確認し、原因を特定することが重要です

#Amazon EMR

#Amazon EC2

おのやん

2024.01.30

Amazon EMRクラスターが動かない

おのやんです。

みなさん、Amazon EMR（以下、EMR）クラスターが動かなくなったことはありませんか？私は何度かあります。

具体的に言うと、マネジメントコンソール上でEMRクラスターを確認した際に、ステータスがずっと「開始中」のまま進まない現象に遭遇しました。

ということで、今回はこちらの原因の調査と対策を行ってみたいと思います。

原因

今回の現象は、EMRクラスターのAmazon EC2（以下、EC2）インスタンスのインスタンスタイプを、デフォルトのm5.xlargeからc1.mediumに変更したことが原因でした。

EMRクラスターを作成する際には、複数のEC2インスタンスが起動されます。この際の料金を節約するために、EC2インスタンスタイプをm5.xlarge（0.248 USD/時間）からc1.medium（0.158 USD/時間）に変えた経緯がありました（こちらの料金はマネジメントコンソール上の数値です）。

スペックを比較すると次の通りです。

インスタンスタイプ	コア数（vCore）	メモリ（GiB）
m5.xlarge	4	16
c1.medium	2	1.7

m5.xlargeのメモリが16GiBであるのに対して、c1.mediumのメモリは1.7GiBでした。これにより、デフォルトの設定で動作するはずのEMRクラスターがメモリ不足で実行不可能になったわけです。

実際にEMRクラスターをクローンして、インスタンスタイプをm5.xlargeに戻してみます。すると、EMRクラスターが正常に実行されるようになりました。

調査方法

この原因に辿り着く際に、どこを調べたのかを共有します。

EMRクラスターの起動が上手くいかない場合の対処法は、こちらのAWS re：Postの質問に記載があります。

ブートストラップアクションが失敗した理由を判断するには、ブートストラップアクションの stderr ログを確認します。これらのログは、Amazon EMR クラスターの作成時に設定した Amazon Simple Storage Service (Amazon S3) のパスまたは LogUri にあります。

この情報を元にS3バケットのログを調べると、確かにstderrログが作成されていました。今回の場合は、あるクラスターの配下にあるノード（EC2インスタンス）が記録しているprovision-node/apps-phase/0/id名にありました。

こちらを開くとログが表示されます。ここでCtrl + Fを押して「error」を検索します。するとログの中にエラー文があるのを確認できます。

'HADOOP_OPTS': '"$HADOOP_OPTS -server -XX:+ExitOnOutOfMemoryError -add-exports=jdk.compiler/com.sun. tools.javac.til=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED

ExitOnOutOfMemoryError、つまりメモリ不足によるエラーでしたね。ここからインスタンスタイプを変更したことを思い出し、原因特定に繋がったわけです。